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(57) Abstract: The invention concerns a method for loading an applet in a smart card (2a), using two loading programmes, a so-called 
In-loader (IL), stored in the card, and Off-loader, respectively. The invention is characterised in that two specific communication 
protocol layers are provided, one in a terminal (1) hosting the card reader, the other in the card. Said layers include in particular 
intelligent agents enabling the card to provide a WEB client/server and a CGI gateway functional capability. The method comprises 
at least one step during which a HTTP request is sent to the card, to address a HTML page, a step which consists in retrieving pa- 
rameterising data transported by a HTML form and a step which consists in executing a second loading programme (IL) using the 
CGI functional capability to load the applet. 

(57) Abrege : L' invention concerne le chargemem d'une "applet" dans une carte a puce (2a), a l'aide de deux programmes de char- 
gement, dits "In-loader" (EL), stocks dans la carte, et "Off-loader" (OL), respectivement. Scion 1' invention, on prevoit deux couches 
protocolaires de communication specifiques, l'une dans un terminal (1) heoergeant le lecteur de la carte, Pautre dans la carte. Ces 
couches comprennent notamment des agents intelligents permettant a la carte d'offrir une fonctionnalite* de client/serveur "WEB" et 
de passerelle "CGI". Le procecte comprend au moins une e*tape pendant laquelle une requeue "HTTP" est envoyee a la carte, pour 
adresser une page "HTML", une gtape de recuperation de donnees de paramefrage v£hiculees par un formulaire "HTML" et une 
e'lape d'execulion du second programme de chargement (IL), parmise en oeuvre de la fonctionnalite* "CGI", pour charge r'Applet". 
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En ce qui concerne les codes d deux lettres et autres abrevia- 
tions, se riferer aux "Notes explicatives relatives awe codes et 
abreviations" figurant au debut de chaque numero ordinaire de 
la Gazette du PCX 
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PROCEDE DE CHARGEMENT D'UNE PIECE DE LOGICIEL DANS UNE 
CARTE A PUCE, NOTAMMENT DU TYPE DIT "APPLET" 

^invention concerne un procede de chargement d'une piece de 
logiciel dans une carte a puce. 

Elle s'applique plus particulierement au chargement d'une piece de 
5 logiciel appel6e en frangais "appliquette", plus connue sous le terme anglo- 
saxon d' "applet". II s'agit d'une application ecrite en langage "JAVA" 
(marque deposee). Ces applications, generalement peu volumineuses, sont 
independantes des architectures des systemes sur lesquelles elles sont 
implantees. Elles peuvent done fonctionner sur n'importe quel systeme 
10 informatique, dans la mesure ou celui-ci implemente le concept dit de 
"machine virtuelle JAVA" ("Java Virtual Machine"). Une application ecrite en 
langage JAVA est en general traduite en un langage intermediate dit "Byte 
Code". La machine virtuelle JAVA precitee constitue un interpretateur de ce 
"Byte Code", de mantere a etre executee directement sur un systeme cible, 
15 hote de ladite machine virtuelle. 

Generalement, les architectures de systeme sur lesquelles tourne 
ce type duplications sont du type dit client-serveur. Dans ce cas, on parle 
egalement de "servlet" pour une application stockee sur un systeme serveur 
et "applet" pour une application stockee sur un systeme client. Dans ce qui 
20 suit, on utilisera le terme "applet" de fa?on g§n6rique. 

Des pieces de logiciel, se presentant sous la forme & "applet" qui 
vient d'etre rappelee, dans la mesure ou la quantity de code n'est pas trop 
volumineuse, peuvent §tre stockees dans une memoire non volatile presente 
sur une carte & puce, au meme titre que toute autre application. 
25 Aussi, le procede selon I'invention est plus particulierement 

concerne par un terminal ou station d'utilisateur muni d'un lecteur de carte a 
"puce". 
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Dans le cadre de Invention, le terme "terminal" doit etre compris 
dans un sens g6neral. Le terminal precite peut etre notamment constitu§ par 
un ordinateur personnel fonctionnant sous divers systfcmes d'exploitation, 
tels WINDOWS ou UNIX (tous deux etant des marques deposees). II peut 
5 §tre aussi constitue par une station de travail, un ordinateur portable ou un 
terminal de carte dit d6di§. 

Dans l'6tat actuel de la technique, le chargement d'une "applet" sur 
une carte a puce (encore appele telechargement) se fait grace a deux 
programmes specifiques. Ces programmes sont generalement connus sous 
w les termes anglo-saxons "Off-Loader", pour le premier, et "In-Loader", pour 
le second. Le programme "Off-Loader" s'execute sur le terminal et le 
programme "In-Loader" s'execute dans la carte a puce. Les programmes de 
chargement "Off-Loader" et "In-Loader" communiquent entre eux au travers 
d'une liaison normalisee de type ISO 781 6-3, protocole universellement 
15 retenu pour les communications entre une carte £ puce et son terminal hote. 
Ce protocole met en ceuvre une suite d'echanges generalement 
proprieties (commandes d'un type dit "APDU" qui seront explicitees ci- 
aprds) afin de realiser le chargement d'une "applet". 

La figure 1A annexee a la presente description illustre de fagon 
20 schematique I'architecture mise en oeuvre pour le chargement d' "applets" 
dans une carte a puce selon Tart connu. 

Le terminal 1 stocke un premier programme specifique de 
chargement ("Off-Loader"), reference OL. II communique avec une carte & 
puce 2, via un lecteur de carte a puce 3. Les transmissions s'effectuent selon 
25 un protocole de communication normalise, faisant appel aux commandes 
precipes, protocole qui sera detaille ci-apres. 

La carte a puce 2, pour sa part stocke un second programme 
sp6cifique de chargement ("In-Loader"), reference IL. 

Un premier inconv6nient de ce proc6de est que les programmes IL 
et OL doivent etre apparies pour pouvoir communiquer entre eux. II s'ensuit 
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que s'ils sont d'origines differentes, ils ne sont pas, a priori, compatibles. 
Cette caracteristique est liee au jeu de commandes & utiliser. 

Un deuxieme inconvenient est du au fait que les communications 
s'effectuent selon le protocole ISO 7816 precite. En effet, celui-ci impose une 
5 proximity physique entre les programmes OL et IL. II s'ensuit que le 
programme OL doit generalement s'ex6cuter directement sur le terminal 1 et 
non, par exemple, sur un autre terminal ou un serveur eloign^. 

Or, avec I'essor spectaculaire du reseau Internet, un nombre 
toujours croissant de terminaux sont connectes a ce reseau, notamment 

10 pour pouvoir etre en liaison avec des serveurs eloignes, de type "WEB". II 
serait done interessant, par exemple, de pouvoir stocker la partie "Off- 
Loader" OL des programmes de chargement d' "applets" sur un serveur 
"WEB" connecte a ce reseau. Les "applets" a charger sur une ou plusieurs 
carte(s) a puce pourraient d'ailleurs etre aussi stock§es sur ce serveur ou 

15 sur un ou plusieurs autres serveurs de ce type. 

Dans I'etat actuel de la technique, ce mode operatoire bute sur une 
double impossibility. La premiere a deja ete evoquee : la norme retenue pour 
les communications entre le terminal et la carte a puce impose a priori une 
proximite physique entre la localisation des programmes "Off-Loader", OL, et 

20 "In-Loader", IL. 

D'autre part, les transmissions entre deux systemes, par exemple 
un terminal et un serveur eloigne, via le reseau Internet, font appel a des 
protocoles de type Internet. Dans I'etat actuel de la technique, il n^st pas 
possible de realiser des communications directes entre une carte a puce et 

25 le reseau Internet, comme il va I'etre explicite egalement. 

Dans le cadre de I'invention, le terme "reseau Internet" englobe, 
outre le reseau Internet proprement dit, les reseaux prives d'entreprises ou 
similaires, du type dit "intranet", et les reseaux les prolongeant vers 
rexterieur, du type dit "extranet", et de fagon generale tout reseau dans 

30 lequel les ^changes de donnees s'effectuent selon un protocole du type 
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Internet. Dans ce qui suit un tel reseau sera appele de fagon g6n6rique 
"r6seau Internet". 

On va tout d'abord rappeler brievement ('architecture generate d'un 
systeme d'application & base de carte a puce, relie a un reseau Internet, par 
5 reference aux figures 1 B et 1 C. 

Un systeme d'application a base de carte a puce comporte 
generalement les elements principaux suivants : 
une carte a puce ; 

un systeme hote constituant le terminal precite ; 
10 - un r6seau de communication, a savoir le reseau Internet dans 

I'application preferee ; 

et un serveur d'application connecte au reseau Internet. 
La figure 1B illustre schematiquement un exemple d'architecture de 
ce type. Le terminal 1 , par exemple un ordinateur individuel, comporte un 
15 lecteur 3 de carte a puce 2. Ce lecteur 3 peut etre ou non physiquement 
integre dans le terminal 1 . La carte a puce 2 comporte un circuit integre 20 
dont des connexions d'entrees-sorties affleurent en surface de son support 
pour autoriser une alimentation en energie 6lectrique et des communications 
avec le terminal 1. Ce dernier comprend des circuits d'acces 11 au reseau 
20 Internet Rl. Ces circuits peuvent etre constitues par un modem pour se 
connecter a une ligne telephonique commutee ou a une voie de 
communication a plus haut d6bit : reseau numerique a integration de 
services ("RNIS"), cable ou liaisons par satellite, etc. Les circuits 11 
permettent de se connecter au reseau Internet Rl, directement ou via un 
25 prestataire de services Internet (Internet Service Provider" ou "ISP", selon la 
terminologie anglo-saxonne). On peut egalement avoir recours a un systeme 
intermediaire tel qu'un "proxy" ou un systeme d'isolation dit "firewall" ("pare- 
feu" ou encore appele "garde barriere"). 

Le terminal 1 comprend naturellement tous les circuits et organes 
30 n6cessaires a son bon fonctionnement, et qui n'ont pas ete represents 
dans un but de simplification du dessin : unite centrale, memoires vive et 
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fixe, m6moire de masso a disque magn§tique, lecteur de disquette et/ou de 
CedeRom, etc. 

Habituellement, le terminal 1 est aussi reli§ a des peripheriques 
classiques, integres ou non, tels un ecran de visualisation 5, un clavier 6a et 
5 une souris 6b, etc. 

Le terminal 1 peut etre mis en communication avec des serveurs ou 
tous systemes informatiques connects au reseau Rl, dont un seul, 4, est 
illustre sur la figure 1A. Les circuits d'acces 11 mettent le terminal 1 en 
communication avec les serveurs 4 grace a un logiciel particulier 10, appel6 
w navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui- 
ci permet d'acceder a diverses applications ou fichiers de donnees repartis 
sur I'ensemble du reseau Rl, generalement selon un mode "client-serveur". 

Habituellement, les communications sur les reseaux s'effectuent 
conformement a des protocoles r6pondant a des standards comprenant 
15 plusieurs couches logicielles superposees. Dans le cas d'un reseau Rl de 
type Internet, les communications s'effectuent selon des protocoles 
specifiques a ce type de communications, qui seront detailles ci-apres, mais 
qui comprennent egalement plusieurs couches logicielles. Le protocole de 
communication est choisi en fonction de ('application plus particulierement 
20 visee: interrogation de pages "WEB", transferts de fichiers, courrier 
Slectronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), 
forums ou "news", etc. 

L'architecture logique du systeme comprenant un terminal, un 
lecteur de carte a puce et une carte a puce, est representee 
25 schematiquement par la figure 1C. Elle est decrite par la norme ISO 7816, 
qui elle-meme comportent plusieurs sous-ensembles : 

ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le 
marquage des cartes ; 

ISO 7816-3, en ce qui concerne le transfert de donnees entre 
30 le terminal et la carte a puce ; et 
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ISO 781 6-4, en ce qui concerne la structure du jeu d'ordres et 
le tormat des commandes. 

Sur la figure 1C, du cote terminal 1, on n'a represents que les 
couches repondant a la norme ISO 7816-3, referencees 101, et un 
5 gestionnaire d'ordres "APDU" (norme ISO 7816-4), reference 102. Du cote 
carte a puce 2, les couches repondant a la norme ISO 7816-3 sont 
referencees 200 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est 
reference 201 . Les applications sont referencees A-\ , A;, A n ; n etant le 
nombre maximum duplications presentes sur la carte a puce 2. 

10 Une application, A,\ presente dans la carte a puce 2, dialogue avec 

le terminal 1 au moyen d'un jeu d'ordres. Ce jeu presente typiquement des 
ordres d'ecriture et des ordres de lecture. Le format des ordres est connu 
sous I'abreviation anglo-saxonne de "APDU" (pour "Application Protocol 
Data Unit"). II est defini par la norme ISO 7816-4 precitee. Une "APDU" de 

15 commande est notee "APDU. command' et une "APDU" de reponse est 
notee "APDU. response". Les "APDU" sont echangees entre le lecteur de 
carte et la carte a puce au moyen d'un protocole specifie par la norme ISO 
7816-3 precitee (par exemple en mode caractere : T=0 ; ou en mode bloc : 
T=1). 

20 Lorsque la carte a puce 2 inclut plusieurs applications distinctes, 

comme illustre sur la figure 1C, on parle de carte multi-applicative. 
Cependant, le terminal 1 ne dialogue qu'avec une seule application a la fois. 
Une application Aj se presente, par exemple, sous la forme d'une "applet" 
qui peut etre enregistree initialement, ou encore chargee a partir du terminal 

25 1. Pour ce faire, comme illustre par la figure 1A, on a recours a un 
programme "Off-Loader", OL, enregistre dans le terminal 1 et a un 
programme "In-Loader", IL, qui forme I'une des applications A\ de la carte a 
puce 2. 

La selection d'une application particuliere A\ est obtenue a I'aide 
30 d'une "APDU" du type selection ("SELECT"). Une fois ce choix effectue, les 
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"APDU" qui le suivent sont achemines vers cette application. Une "APDU 
SELECT" nouvelle a pour effet d'abandonner I'application en cours et d'en 
choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 
permet de choisir une application particuliere A\ dans la carte a puce 2, de 
5 memoriser Implication ainsi choisie, et de transmettre et/ou recevoir des 
"APDU" vers et depuis cette application. 

En resume de ce qui vient d'etre decrit, la selection d'une 
application Aj et le dialogue avec celle-ci s'effectuent par echanges d'ordres 
"APDU". On suppose que les applications Aj sont des applications 
10 conventionnelles, que Ton appellera ci-apres M GCA" (pour "Generic Card 
Application" ou application de carte generique). 

Ce mode operatoire explique que les programmes OL et IL doivent 
etre apparies, pour que les ordres "APDU" echanges puissent etre 
compatibles et compris par ces deux applications. 
is Ces rappels etant effectues, il est a noter que la carte a puce 2 ne 

peut communiquer directement avec les navigateurs standards du 
commerce, sauf a modifier le code de ces derniers. 

En outre, et surtout, les cartes a puce actuelles, qui par ailleurs sont 
conformes aux standards et normes rappeles ci-dessus, ont une 
20 configuration materielle et logicielle qui ne permet pas non plus de 
communiquer directement avec le r§seau Internet. En particulier, elles ne 
peuvent recevoir et transmettre des paquets de donnees, selon I'un ou 
Tautre des protocoles utilises sur ce type de reseau. II est done necessaire 
de prevoir une piece de logiciel additionnelle, implantee dans le terminal 1 , 
25 generalement sous la forme de ce qui est appele un "plug-in", selon la 
terminologie anglo-saxonne. Cette piece de logiciel, qui porte la reference 12 
sur la figure 1B, effectue I'interface entre le navigateur 10 et la carte 2, plus 
precisement les circuits electroniques 20 de cette carte 2. 


WO 01/59563 PCT/FR01/00393 

8 

L'invention vise a pallier les inconvenients des procectes et 
dispositifs de Tart connu, et dont certains viennent d'etre rappeles, tout en 
repondant aux besoins qui se font sentir. 

Selon une premiere caracteristique de invention, les deux 
5 programmes de chargement, OL et IL ne sont plus dependants Tun de 
I'autre. En d'autres termes, ils n'ont plus a etre apparies pour etre 
compatibles. 

Selon une deuxieme caracteristique de invention, la partie OL des 
programmes de chargement n'a plus a etre stockee obligatoirement dans le 

w terminal, c'est-a-dire en relation de proximite physique avec la seconde 
partie IL. Tout au contraire, le programme OL peut etre stocke sur un 
serveur eloigne, connecte au terminal via un reseau de type Internet. 

Pour ce faire, et selon une autre caracteristique de invention, la 
carte a puce se comporte comme un serveur/client de type "WEB" pour le 

15 terminal qui lui est associe. 

Pour atteindre ce but, on prevoit une couche de logiciel de 
communication specifique dans la carte a puce et son pendant dans le 
terminal. Le terme "specifique" doit etre entendu comme specifique au 
procede de I'invention. En effet, ces couches de communications, dites 

20 sp§cifiques, sont banalisees quelle que soit Implication consideree. Elles 
n'interviennent que dans le processus d'echanges de donnees 
bidirectionnels entre la carte a puce et le terminal, d f une part, et la carte a 
puce et le reseau, d'autre part. 

Les couches logicielles de communication specifiques comprennent 

25 notamment des composants logiciels, dits "agents intelligents", permettant 
en particulier des conversions de protocoles. Les agents intelligents seront 
appeles ci-apres plus simplement "agents". II existe des agents appareilles 
dans les couches de communication specifiques respectives associees au 
terminal et a la carte a puce. Selon le procede de I'invention, il s'etablit des 

30 sessions entre agents appareilles. 
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Selon une au:re caracteristique, le proc6d6 de I'invention rend 
possible I'activation duplications de type conventionnel, c'est-a-dire du type 
"CGA" precite, localisees dans une carte a puce, sans devoir les modifier en 
quoi que ce soit. 

5 Pour ce faire, on prevoit un ou plusieurs agents intelligents 

particuliers dits traducteurs de script, qui regoivent des requetes d'un 
navigateur et les traduisent en ordres "APDU" comprehensibles par 
Tappiication de type "CGA". De ce fait, on implante dans la carte a puce une 
fonction similaire a celle connue par ailleurs sous la denomination "CGI" 

10 dans les serveurs "WEB" classiques. Cette fonction permet de mettre en 
oeuvre une application dans la carte a puce par un protocole Internet de type 
"HTTP". 

Le chargement d'une "applet" dans la carte a puce peut s'effectuer 
par cette interface "CGI". La partie IL du programme de chargement est 

15 consider^ comme etant un script de commandes, que Ton appellera "cgi- 
script", attache a la fonctionnalite serveur "WEB" offerte par la carte a puce. 
Les echanges entre les programmes OL et IL peuvent se derouler avec 
Taide de formulaires classiques en langage "HTML" ou "forms" selon la 
terminologie anglo-saxonne. 

20 Tout en conservant les normes ISO pr6citees pour les 

communications entre terminal et carte a puce, via le lecteur de carte a 
puce, le procede selon I'invention permet des echanges entre les parties de 
programmes de chargement OL et IL en faisant appel au protocole de 
communication Internet "TCP/IP", la partie OL et les "applets" a charger 

25 pouvant etre stockees en local ou dans un serveur eloigne. 

^invention a done pour objet principal un proc6d§ de chargement 
d'une piece de logiciel dans une carte a puce a partir d'un terminal connecte 
a ladite carte a puce par I'intermediaire d'un lecteur de carte a puce 
permettant des communications selon un premier protocole determine, ledit 
30 chargement s'effectuant par la mise en oeuvre et la cooperation de premier 
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et second programmes de chargement, ledit second programme de 
chargement etant stocke dans ladite carte a puce, caracterise en ce qu'il 
comprend au moins les phases suivantes : 

aJ une premiere phase preliminaire consistant a implanter, dans 
5 ladite carte a puce, une premiere piece de logiciel, formant une couche 

protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal, une seconde ptece de logiciel, formant une couche 
protocolaire de communication specifique ; 
10 en ce que lesdites premiere et seconde pieces de logiciel comprennent 

en outre au moins une paire de premieres entites logicielles appariees, 
chacune desdites entites cooperant Tune avec Pautre de maniere a 
permettre I'etablissement d'une session d'echanges de donnees 
bidirectionnels entre au moins ledit terminal et ladite carte a puce, de 
15 maniere a ce que ladite carte & puce offre la fonctionnalite d ? un client/serveur 
"WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce au moins une deuxieme entite logicielle, 
apte a interpreter une suite ^instructions et a la traduire en une suite 
20 d'ordres, de maniere a cooperer avec ladite seconde piece de logiciel 
specifique pour que ladite carte a puce offre une fonctionnalite d'interface 
passerelle dite "CGI", la dite carte a puce comprenant au moins une desdites 
suites destructions associee au dit second programme de chargement ; 
et en ce qu'il comprend au moins les etapes suivantes : 
25 1/ ouverture d'une premiere session d'echanges de donnees 

entre au moins ledit terminal et ladite carte a puce, pour la transmission 
d'une requete pour que ledit premier programme de chargement 
recupere des donnees de parametrage de chargement fournies par 
ledit second programme de chargement ; 


01/59563 PCT/FR01/00393 

11 

21 ouverture d'une deuxteme session d'echanges de donn6es 

entre ladite carte k puce et au moins ledit terminal pour transmettre 
lesdites donnees de param6trage de chargement au dit premier 
programme de chargement, lesdites donnees de param§trage 
comportant une reference aux dites instructions associees au dit 
second programme de chargement ; et 

3/ ouverture d'une troisieme session d'echanges de donnees 
entre au moins ledit terminal et ladite carte a puce, pour la soumission d'un 
fichier de chargement prenant en compte lesdites donn6es de parametrage 
de chargement, ledit fichier comprenant des donnees representant ladite 
piece de logiciel a charger; interpretation de ladite suite destructions 
associee au dit second programme de chargement, par mise en oeuvre de 
ladite fonctionnalite "CGI", de maniere generer une suite d'ordres transmise 
au dit second programme de chargement, a exporter ce programme et a 
obtenir ledit dechargement de ladite piece de logiciel. 

L'invention va maintenant etre decrite de fagon plus detaillee en se 
referant aux dessins annexes, parmi lesquels : 

la figure 1A illustre sch6matiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
carte a puce selon Tart connu ; 

les figures 1B et 1C illustrent les architectures materielle et 
logique, respectivement, d'un exemple de systeme d'application a 
base de carte a puce connecte a un reseau Internet selon Tart 
connu, ; 

la figure 2 illustre schematiquement un exemple de systeme 
d'application k base de carte a puce selon l'invention, cette derntere 
agissant en tant que client/serveur "WEB" ; 

la figure 3 est un diagramme d'etats d'une session entre des 
entites logicielles dites agents intelligents, selon un aspect de 
l'invention ; 
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la figure 4 illustre de fa?on simplifiee Parchitecture logique d'un 
systerne selon I'invention dans lequel la carte a puce comprend des 
agents intelligents ; 

la figure 5 illustre de fagon simplifiee I'architecture logique d'un 
5 systerne selon invention dans lesquels la carte a puce comprend 

des agents intelligents traducteurs de scripts ; 

la figure 6 illustre schematiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
carte a puce selon I'invention ; 
10 - la figure 7 illustre la structure d'un fichier de chargement d'une 

"applet" pouvant etre en oeuvre par le procede selon ('invention ; 

la figure 8 illustre schematiquement les phases principales du 
procede de chargement d'une "applet" dans une carte a puce selon 
un premier exemple de realisation pratique ; 
15 - la figure 9 illustre schematiquement les phases principales du 

procede de chargement d'une "applet" dans une carte a puce selon 
un deuxieme exemple de realisation pratique ; 

les figures 9 et 10 illustrent deux exemples de formulaires en 
langage "HTML" utilisables par le procede de chargement d'une 
20 "applet" dans une carte a puce selon I'invention, pour la mise en 

oeuvre des methodes dites "GET" et "POST", respectivement ; et 

les figures 12A a 12G illustrent plusieurs variantes de 
realisation de realisation d'architectures de systemes permettant le 
chargement d'une "applet" dans une carte a puce selon I'invention. 
25 Dans ce qui suit, sans en limiter en quoi que ce soit la portee, on se 

placera ci-apres dans le cadre de ('application preferee de I'invention, sauf 
mention contraire, c'est-a-dire dans le cas d'un terminal connecte a un ou 
plusieurs serveurs eloign6s via le reseau Internet. 

Avant de decrire le procede d'activation duplications localisees 
30 dans une carte a puce selon I'invention et de detainer une architecture pour 
sa mise en oeuvre, par reference a la figure 2, il apparait tout d'abord utile de 
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rappeler brievement les caracteristiques principales des protocoles de 
communication sur les reseaux. 

^architecture des reseaux de communication est decrite par 
diverses couches. A titre d'exemple, le standard "OSI" ("Open System 
5 Interconnection"), defini par I' "ISO", comporte sept couches qui vont des 
couches dites basses (par exemple la couche dite "physique" qui concerne 
le support de transmission physique) aux couches dites hautes (par exemple 
la couche dite "d'application"), en passant par des couches intermediates, 
notamment la couche dite de "transport". Une couche donnee offre ses 

10 services a la couche qui lui est imm6diatement superieure et requiert de la 
couche qui lui imm6diatement inferieure d'autres services, via des interfaces 
appropriees. Les couches communiquent a I'aide de primitives. Elles 
peuvent egalement communiquer avec des couches de meme niveau. Dans 
certaines architectures, plusieurs couches peuvent etre inexistantes. 

15 Dans un environnement de type Internet, les couches sont au 

nombre de cinq, et de fagon plus precise, en allant de la couche superieure 
£ la couche inferieure : la couche dite d'application ("http", "ftp", "e-mail", 
etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de 
reseau ("IP"), la couche dite de liens de donnees ("PPP", "Slip", etc.) et la 

20 couche dite physique. 

Si on se reporte de nouveau a la figure 2, a Texception de couches 
logicielles de protocole de communication specif iques, r§f§rencees 13 et 
23a, respectivement implantees dans le terminal 1 et la carte a puce 2a, les 
autres Elements, materiels ou logiciels, sont communs a Tart connu, et il n'y 

25 a pas lieu de les re-d6crire de fagon detaillee. 

Le terminal 1 comprend des circuits 11 d'acces au reseau /?/, 
constitues par exemple d'un modem. Ces circuits regroupent les couches 
logicielles inferieures, Ci et C2, qui correspondent aux couches "physique" 
et de "lien de donnees". 
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On a egalement represents les couches superieures, C3 et 04, qui 
correspondent aux couches "d'adressage de reseau" ("IP", dans le cas 
d'lnternet) et de "transport" ("TCP"). La couche superieure duplication 
("http", "ftp", "e-mail", etc.) n f a pas et6 representee. 
5 ^interface entre les couches inferieures, C1 et C2, et les couches 

superieures, C3 et C4, est constitute par une couche logicielle 
generalement appelee "driver couches basses". Les couches superieures, 
C3 et C4, s'appuient sur cette interface et sont mises en oeuvre par 
I'intermediaire de bibliotheques de fonctions specifiques ou bibliotheques 
10 reseau 14, avec lesquelles elles correspondent. Dans le cas du reseau 
Internet, "TCP/IP" est mis en oeuvre au moyen de bibliotheques dites de 
"sockets". 

Cette organisation permet a un navigateur 1 0 de poser des requetes 
vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), 

15 pour le transfert de fichiers (protocole "FTP") ou renvoi de courrier 
electronique (protocole "e-mail"), ce de fagon tout a fait classique en soi. 

Le terminal 1 comprend egalement un lecteur de carte 3, integre ou 
non. Pour communiquer avec la carte a puce 2a, le lecteur de carte 30 
englobe egalement deux couches basses, CC1 (couche physique) et CC2 

20 (couche de lien de donnees), jouant un role similaire aux couches C1 et C2. 
Les interfaces logicielles avec les couches CC1 et CC2 sont decrites, par 
exemple, par la specification "PC/SC" ("part 6, service provider"). Les 
couches elles-memes, CC1 et CC2, sont notamment decrites par les normes 
ISO 7816-1 a 7816-4, comme il a ete rappele. 

25 Une couche logicielle supplemental 16 forme interface entre les 

couches applicatives (non representees) et les couches inferieures, CC1 et 
CC2. La fonction principale d§volue a cette couche 16 est une fonction de 
multiplexage/demultiplexage. 

Les communications avec la carte a puce 2a s f effectuent selon un 

30 paradigme similaire a celui utilise pour la manipulation de fichiers dans un 
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systeme Sexploitation du type "UNIX" (marque deposee) : OUVRIR 
("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc. 

Du cote de la carte a puce 2a, on retrouve une organisation 
similaire, a savoir la presence de deux couches basses, referencees CCai 
5 (couche physique) et CCa2 (couche de lien de donn6es), ainsi qu'une 
couche d'interface 26a, tout a fait similaire & la couche 16. 

Selon une premidre caracteristique de I'invention, on prevoit, de part 
et d'autre, c'est-a-dire dans le terminal 1 et dans la carte a puce 2a, deux 
couches de protocoles sp6cifiques : 13 et 23a, respectivement. 
10 Dans le terminal 1, la couche specifique 13 s'interface aux "drivers 

couches basses" 15, aux bibliotheques 14 des couches reseau, C3 et C4, et 
aux couches protocolaires du lecteur de carte 3, c'est-a-dire les couches 
inferieures, CC1 et CC2, via la couche de multiplexage 16. La couche 
specifique 13 permet le transfert de paquets reseaux de et vers la carte a 
15 puce 2a. En outre, elle adapte les applications existantes telles le navigateur 
Internet 10, le courrier electronique, etc., pour des utilisations mettant en 
oeuvre la carte a puce 2a. 

Du cote de la carte a puce 2a, on retrouve une organisation tout a 
fait similaire constitute par une instance supplemental de la couche 
20 specifique, referencee 23a, pendant de la couche 13. 

De fagon plus precise, les couches specif iques, 13 et 23a, sont 
subdivisees en trois elements logiciels principaux : 

un module, 130 ou 230a, de transfert de blocs deformations 
entre les couches 13 et 23a, via les couches conventionnelles CCi, CC2, 
25 CCai et CCa2 ; 

une ou plusieurs pieces de logiciel, dites "agents intelligents", 
132 ou 232a, qui realisent, par exemple, des fonctions de conversion de 
protocoles ; 
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et un module de gestion de la configuration specifique, 131 et 
231a, respectivement ; module qui peut etre assimile a un agent intelligent 
particulier. 

Pour simplifier, on appellera ci-apres les agents intelligent^, 
5 "agents", comme il a ete precedemment indique. 

On retrouve done, dans le terminal 1 et la carte a puce 2a, une pile 
protocolaire de communication entre les deux entites. 

Les couches de niveau deux (couches de lien de donnees), CC2 et 
CCa2, assurent I'echange entre la carte a puce 2a et le terminal 1. Ces 
10 couches sont responsables de la detection et I'eventuelle correction 
d'erreurs de transmission. Differents protocoles sont utilisables, et a titre 
d'exemples non exhaustifs les suivants : 

la recommandation ETSI GSM 11.11 ; 

le protocole defini par la norme ISO 7816-3, en mode caractere 

15 T=0 ; 

le protocole defini par la norme ISO 7816-3, en mode bloc T=1 

» 

ou le protocole defini par la norme ISO 3309, en mode trame 
"HDLC" (pour "High-Level Data Link Control procedure" ou procedure de 
20 commande de liaison a haut niveau). 

Dans le cadre de I'invention, on utilisera de preference le protocole 
ISO 7816-3, en mode bloc. 

De fagon connue en soi, a chaque couche de protocole, il est 
associe un certain nombre de primitives qui permettent les echanges de 
25 donnees entre couches de meme niveau et d'une couche a I'autre. A titre 
d'exemple, les primitives associees a la couche de niveau deux sont du type 
"demande de donnees" ("Data.request") et "envoi de donnees" par la carte 
("Data.response"), ainsi que "confirmation de donnees" ("Data.confirm"), etc. 
De facon plus specifique, les couches 13 et 23a sont chargees du 
30 dialogue entre la carte a puce 2a et I'hote, e'est-a-dire le terminal 1 . Ces 


•« 
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couches permettent lechange conformations entre un utilisateur (non 
repr6sente) du terminal 1 et la carte a puce 2a, par exemple via des menus 
deroulants sous la forme d'hypertexte au format "HTML". Elles permettent 
aussi la mise en place d'une configuration adaptee pour remission et/ou la 
5 reception de paquets de donnees. 

Comme il a ete indique ci-dessus, les couches comprennent trois 
entites distinctes. 

La premiere couche, 130 ou 230a, est essentiellement constitute 
par un multiplexeur logiciel. Elle permet I'Schange d'informations entre la 
10 carte a puce 2a et le terminal hote 1 , sous la forme d'unites de donnees de 
protocole. Elle joue un role similaire a celui d'un commutateur de paquets de 
donnees. Ces unites sont emises ou regues via la couche de niveau deux 
(couche de liens de donn§es). Ce protocole particulier de communication 
permet de mettre en communications au moins une paire d' "agents". Le 
15 premier agent de chaque paire, 132, est situe dans la couche 13, cote 
terminal 1 , le second, 232a, est situe dans la couche 23a, cote carte a puce 
2a. Une liaison entre deux "agents" est associ§e a une session, que Ton 
pourra appeler "S-Agenf\ Une session est un echange de donnees 
bidirectionnel entre ces deux agents. Si Tune ou I'autre des couches, 13 et 
20 23a, comporte plusieurs agents, les agents d'une meme couche peuvent 
aussi etablir de sessions entre eux et/ou avec les modules 131 et 231a, qui 
constituent des agents particuliers. 

De fagon plus precise, un agent est une entite logicielle autonome 
qui peut realiser tout ou partie de fonctions des couches de niveau trois et 
25 quatre, en fonction de la configuration mise en ceuvre par le terminal 1 . 

Les agents sont associes a des propri§t6s ou attributs particuliers. 
Pour fixer les id6es, et a titre d^xemple non limitatif, les six proprietes 
suivantes sont associees aux agents : 

"hote" : agent localise dans le terminal ; 
30 - "carte" : agent localise dans la carte a puce ; 

"local" : agent ne communiquant pas avec le reseau ; 
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"reseau" : agent communiquant avec le reseau (cote terminal) ; 
"client" : agent qui initialise une session ; 
"serveur" : agent qui re?oit une demande de session. 
Un agent particulier est identify par une reference, par exemple un 
5 nombre entier de 16 bits (c'est-a-dire compris entre 0 et 65535). Le bit de 
poids fort (b15 = 1) indique si la reference est locale (communications 
locales a la carte a puce ou au terminal) ou distante (b15 = 0). 

II existe deux grandes categories d'agents : les agents de type 
"serveur", qui sont identifies par une reference fixe, et les agents de type 
w "client", qui sont identifies par une reference variable, que Ton peut qualifier 
d'ephemere, delivree par le module de gestion de configuration, 131 ou 
231a. 

Les agents communiquent entre eux a I'aide d'entite dites "unites de 
donnee de protocole" ou "pdu n (pour "protocol data unit", selon la 
15 terminologie anglo-saxonne) constituant une reference de destination et une 
reference de source. On pourrait egalement appeler cette "pdu" particuliere 
"SmartTP pdu", en reference au terme anglais "Smart Card" (carte a puce) 
couramment utilise, Les "pdu n utilisent notamment les references definies ci- 
dessus. 

20 Une "SmartTP pdu", ou plus simplement "pdu" ci-apres, comporte 

une reference source, une reference de destination, un ensemble de bits 
constituant des drapeaux ou "flags" qui precisent la nature de la "pdu", et 
des donnees optionnelles : 

- le drapeau "OPEN" 1 (ouvert) est positionne pour indiquer I'ouverture 
25 d'une session ; 

- le drapeau "CLOSE" (ferme) indique la fermeture d'une session ; et 

- Le drapeau "BLOCK" (verrouille) indique que I'agent est en attente d'une 
reponse de son correspondant et suspend toute activite. 

On appellera jeton une "pdu" qui ne comporte pas de donnees. 
30 L'entite "SmartTP" controle ('existence de I'agent destinataire et 

realise la commutation d f un paquet vers ce dernier. 
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Une session agent "S-Agent 1 possdde trois etats remarquables, & 

savoir : 

- un etat deconnecte : aucune session n'est ouverte avec un autre agent 

- un etat connecte : une session est ouverte avec un autre agent, une 
5 session "S-Agent 1 etant identifiee par une paire de references ; et 

- un etat bloqu6, I'agent etant connecte et attendant une reponse de son 
correspondant. 

Le mecanisme d'etablissement d'une session "S-Agent" est le 

suivant : 

10 - une nouvelle instance d'un agent client est creee (cote carte a puce ou 
terminal), cet agent etant identifie par une reference ephemere pseudo- 
unique ; 

- I'agent client emet une "pdu" a destination d'un agent serveur (dont la 
reference est connue par ailleurs) avec le drapeau "OPEN" positionne et 

15 I'agent client passe a I'etat connecte ou bloque selon la valeur du drapeau 
"BLOCK 1 ' ; et 

- I'agent serveur regoit la "pdu" avec le drapeau "OPEN" et passe a I'etat 
connecte 

Une fois une session ouverte, deux agents echangent des donnees 
20 via des "pdu". 

Le mecanisme de fermeture d'une session est le suivant : 

- un agent emet une "pdu" avec le drapeau "CLOSE' positionne (et 
qui comporte 6ventuellement des donnees ; et 

- Pautre agent regoit une "pdu" avec le drapeau "CLOSE' positionne 
25 (et qui comporte eventuellement des donnees) et la session "S-Agent" passe 

a I'etat deconnecte. 

La figure 3 illustre de fagon schematique le diagramme d'etats des 
sessions "S-Agent", telles qu'elles viennent d'etre rappelees. 

Les couches 130 et 230a gerent des tables (non representees) qui 
30 contiennent la liste des agents presents, cote terminal hote 1 et carte a 
puce 2a. 
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De fagon pratique, les agents permettent exchanger des donates 
(de I'hypertexte, par exemple), mais egalement de dSclencher des 
transactions reseau, autorisant des communications entre la carte a puce 2a 
et un serveur eloigne 4 (figure 2). 
5 Les modules de gestion de configuration, 131 et231a, 

respectivement, sont assimilables a des agents particuliers. Par exemple, le 
module 131 , cote terminal hote 1 , gere notamment des informations relatives 
a la configuration de ce terminal (modes de fonctionnement), liste des autres 
agents presents, etc. Le module 231a, cote carte a puce 2a, a des fonctions 

10 analogues. Ces deux agents peuvent etre mis en communication Tun avec 
I'autre pour etablir une session. 

De fagon pratique, la carte a puce 2a est avantageusement 
"adressee" par utilisation d'une adresse "URL" (pour "Universal Resource 
Locator") definissant un rebouclage sur le terminal 1 lui-meme, et non un 

15 pointage sur un serveur externe. A titre d'exemple, la structure de cette 
"URL" est habituellement la suivante : 

http://1 27.0.0.1:8080 (1), 
dans laquelle 127.0.0.1 est I'adresse "IP" de rebouclage et8080 est le 
numero de port. 

20 La figure 4 illustre de fagon simplifiee I'architecture logique d'un 

systeme selon I'invention du type represents sur la figure 2, mais represents 
de fagon plus detaillee. La carte a puce 2a comprend plusieurs agents, dont 
deux seulement ont ete represents : un agent de type non precisement 
defini 232ai et un agent 232a2, de type dit "WEB". La pile logique 

25 comprend, les couches de protocole inferieures, rSferencees 200a, 
repondant aux normes ISO 7816-3 (figure 2 : CCai et CCa2), le gestionnaire 
de commandes "APDU" 201 ai, et le multiplexeur de paquets 230a, ce 
dernier etant interface aux agents, notamment I'agent "WEB" 231 a2 

Du cote terminal, il existe deux piles, Tune communiquant avec le 

30 reseau Internet ff/, I'autre avec la carte a puce 2a. La premiere pile 
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comprend les organes 1 1 (figure 2 : Ci et C2) d'acces au reseau (normes 
OSI 1 et 2) et les couches de protocole n TCP/IP" (figure 2 : C3 et C4), 
referencees 1 00. Ces dernieres couches sont interfacees avec le navigateur 
"WEB" 10. L'autre pile comprend les couches de protocole inferieures, 
5 referencees 101, repondant aux normes ISO 7816-3 (figure 2 : C1 et C2). le 
gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce 
dernier etant interface avec des agents, dont un seul 132, est represents. Ce 
dernier, que Ton supposera de "type reseau", peut en outre communiquer, 
d'une part avec le navigateur 10, via les couches "TCP/IP" 101, d'autre part 

10 avec le r§seau Internet Rl, via ces memes couches "TCP/IP" 101 et Porgane 
1 1 , d'acces au reseau RL 

Le gestionnaire d'ordres "APDU" 201a est egalement interface avec 
une ou plusieurs couches de niveau applications, que Ton appellera 
simplement applications. Ces applications, A u A x% A n , sont, comme il a 

15 ete indique, des applications de type conventionnel. 

En resume, la fonction client/serveur "WEB", fournie par la carte a 
puce 2a, peut etre realisee par I'association de I'agent "WEB" 232ai dans la 
carte a puce et de I'agent reseau 132 dans le terminal 1, et par la mise en 
oeuvre de sessions entre agents, comme il a ete decrit. 

20 La carte a puce 2a presente done bien la fonctionnalite 

client/serveur "WEB". En outre, selon une caracteristique du procede de 
('invention, nlmporte quelle application conventionnelle, A-\ k A n , du type 
"CGA" precite, peut etre activee au travers de ce client/serveur "WEB", soit 
par le navigateur "WEB" 10 present dans le terminal 1 , soit par un navigateur 

25 eloigne 4, localise en un point quelconque du reseau Internet Rl, par la mise 
en oeuvre de sessions entre agents. Selon le proc§d§ de I'invention, les 
applications, >Ai a A n , ne necessitent pas d'etre re-ecrites et sont mises en 
oeuvre telles quelles. 

Dans le cadre de I'invention, tout ou partie des applications A\ a A n 

30 peut etre constitute par des "applets", charg6es initialement dans une 
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memoire non volatile de la carte a puce 2 ou, au contraire, chargees par 
I'intermediaire des deux programmes de chargement OL et IL, dont on 
precisera ci-apres la nature et les lieux de stockage possible. 

Selon un autre aspect de invention, la fonction serveur "WEB" 
5 offerte par la carte a puce inclut un mecanisme similaire a la fonction dite 
"CGI" (pour "Common Gateway Interface" ou "interface de passerelle") 
implantee dans les serveurs "WEB" classique. 

Avant de decrire un exemple d'architecture conforme a 1'invention, 
permettant de realiser une fonction de ce type, au sein meme de la carte a 
10 puce, il est utile de rappeler les principales caracteristiques d'un mode de 
fonctionnement "CGI". 

Le "CGI" est une specification de mise en oeuvre, depuis un serveur 
"WEB", duplications ecrites pour les systemes d'exploitation "UNIX" 
(marque deposee), "DOS", ou "WINDOWS" (marque deposee). A titre 
15 d'exemple, pour le systeme d'exploitation "UNIX", la specification est 
"CGI 1.1" et pour le systeme d'exploitation "WINDOWS 95", la specification 
est "CGI 1.3". 

Toujours a titre d'exemple, une requete "HTTP" pour une adresse 
"URL", du type : 

20 "http://www.host.com/cgi-bin/xxx.cgi" (2), 

dans laquelle "host" se refere a un systeme hote (generalement eloigne), 
est interpretee par un serveur "WEB" comme Texecution d'un script de 
commande, de type "CGI" nomme "xxx" et present dans le repertoire "cgi- 
bin" de ce systeme hote. Bien que le nom du repertoire puisse etre a priori 

25 quelconque, par convention, c'est le nom donne au repertoire stockant les 
scripts de type "CGI". Un script est une suite destructions du systeme 
d'exploitation du systeme hote dont le resultat final est transmis au 
navigateur "WEB" emetteur de la requete precitee. Differents langages 
peuvent etre utilises pour ecrire ce script, par exemple le langage "PERL" 

30 (marque deposee). 
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De fagon pratique, la requete est habituellement affichee sur un 
ecran informatique sous la forme d'un formulaire compris dans une page 
"HTLM". Le langage "HTLM" permet de traduire un formulaire en une 
adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires 
5 ou non, qui sont remplis par un utilisateur a Taide des moyens de saisie 
habituels : clavier pour le texte, souris pour les cases a cocher ou les 
boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'eventuellement 
des informations et instructions dites "cachees") est emis a destination du 
serveur "WEB". Le code "HTLM" de la page decrit la structure materielle du 
w formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi que la 
structure des champs de donnees a saisir (nom, longueur, type de donnees, 
etc.). 

La transmission peut s'effectuer selon deux types de formats 
principaux. Un premier format utilise la m6thode dite "POST" et un second la 
15 methode dite "GET". Une information de type de format est presente dans le 
code de la page formulaire. 

Ce m§canisme n'est cependant pas directement transposable a une 
carte a puce, meme si celle-ci offre la fonctionnalite client/serveur "WEB" 
conformement a Tune des caracteristiques de I'invention. 
20 On va maintenant decrire un exemple d'architecture permettant 

d'activer une application quelconque, de type conventionnel, via un serveur 
"WEB" sur la carte a puce, par reference a la figure 5. 

Parmi les agents intelligents, conforme a Tun des aspects de 
I'invention, on prevoit des agents intelligents particuliers, que Ton appellera 
25 ci-apres "Agents traducteurs de script" ou de fagon abregee "ATS". Le script 
est alors interprets par un des agents intelligents. Cette traduction peut etre 
realisee de differentes manieres : 

a/ par I'agent "WEB" 232ai lui-meme, qui est dote dans ce cas d'une 
double capacite ; 
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b/ par un agent script unique capable de traduire I'ensemble des scripts 
presents dans la carte a puce 2a ; 

c/ par un agent de script dedie que Ton appellera "ATSD" ci-apres (un 
agent par script) ; ou 
5 d/ par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, 
qui est dote, dans ce cas, d'une double capacite. 

L'agent "APDU" 2010a est une composante de la couche 
gestionnaire d'ordres "APDU" 201a. Cette derniere est une couche capable 
de centraliser tous les ordres "APDU" emis et/ou recus par le systeme, de 
10 selectionner des applications, parmi A, a A n , mais egalement d'offrir une 
interface de type agent intelligent. Elle est done capable, selon I'une des 
caracteristiques de I'invention de communiquer avec tous les agents 
intelligents (via des sessions), que ces agents soient localises dans 
I'enceinte 6 ou la carte a puce 2a. 
15 Dans le cas c/ ci-dessus, une session est ouverte entre l'agent 

"WEB" 232ai et I'un des agents "ATSD". 

La figure 5 illustre un exemple d'architecture pour laquelle les 
agents traducteurs sont du type "ATSD". lis sont references ATS, a ATS„ et 
associes aux applications A 1 a A n . L'application selectionnee etant supposee 
20 etre l'application A., la session s'etablit entre l'agent "WEB" 232ai et l'agent 
ATS.. 

t 

Un agent traducteur de script genere une suite d'ordres "APDU". 
Une session est ouverte entre l'agent traducteur, par exemple l'agent ATS., 
et l'agent "APDU" 2101a. Les ordres sont alors emis vers l'agent 
25 "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a selectionne 
l'application "CGA" A. et lui transmet les ordres "APDU", ordres traduits et 
done conventionnels, qu'elle est en mesure de comprendre. Cette 
application est done correctement activee, sans avoir & la modifier ou a la 
r66crire. 
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Les reponses de Tapplication A sont transmises au gestionnaire 
d'ordres "APDU" 210a, £ I'agent "APDU" 2010a, puis de nouveau £ ragent 
ATS. (et de fagon plus generale a I'agent traducteur de script). 

Les differents cheminements sont represents symboliquement sur 
5 la figure 5 par des traits pleins reliant les blocs fonctionnets, ou en pointilles 
a I'interieur de ces blocs. 

Le procede selon I'invention utilise les deux caracteristiques qui 
viennent d'etre rappelees : fonctionnement de la carte a puce en tant que 
serveur/client "WEB", incluant une fonction "cgi". Le chargement d'une 
10 "applet" dans la carte a puce s'effectue en effet via ('interface "CGI" offerte 
par celle-ci. 

De fagon plus precise, selon une caracteristique de Tinvention, la 
partie de programme de chargement IL, localisee dans la carte a puce 2a, 
est constitute par un script. II s'agit, par exempie, d'un script associe a 

15 I'application referencee A i sur la figure 5. Ce script est, selon une 
caracteristique du procede de I'invention, active par une requete "HTTP", les 
echanges entre la partie OL et la partie IL s'effectuant selon le protocole de 
communication "TCP/IP". Les programmes IL et OL deviennent de ce fait a 
priori compatibles. En outre, il n'est plus necessaire que la proximity 

20 physique soit respectee, comme dans I'art connu (voir figure 1). La partie OL 
peut desormais etre localisee dans le terminal ou, de preference, dans un 
serveur eloigne (les liaisons entre le serveur et le terminal s'effectuant 
suivant le protocole "TCP/IP"), voire, comme il le sera montre, 6tre stockee 
dans la carte a puce elle-meme. La requete "HTTP" precitee est initiee par la 

25 partie OL. 

II convient de remarquer que les donnees adressees a I'agent 
"WEB" 232ai sont transportees, de fagon conventionnelle en soi, sous 
formes d'ordres "APDU" destines & I'application particuliere constitute par le 
"Multiplexer de paquets" 230a. Le gestionnaire d'ordres "APDU" 201a 
30 selectionne cette application de maniere tout a fait similaire aux autres 
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applications de type "CGA", A-\ a A n , presentes dans la carte a puce 2a. En 
d'autres termes, le multiplexeur de paquets 230a est vu par le gestionnaire 
d'ordres "APDU" 201a comme une application "CGA" ordinaire. 

La requete "HTTP" est analysee par I'agent "WEB" 232ai qui 
5 detecte une reference a un repertoire particulier, que Ton appellera ci-apres 
par convention "cgi-smart" (par analogie a "cgi-bin"), d'une part, et a une 
application particuliere, IL dans le cas de I'exemple decrit. Le chemin 
complet est done, en Toccurrence "cgi-smart/il". 

Selon une caracteristique du procede de I'invention, I'entite "il" ci- 
10 dessus designe un script particulier associe une application egalement 
particuliere (IL en I'occurrence). 

Une session est ouverte entre I'agent traducteur, par exemple 
I'agent ATS\ t et I'agent "APDU" 2010a. L'agent traducteur de script ATS\ 
genere une suite d'ordres "APDU". Les ordres sont emis vers I'agent 
15 "APDU" 2010a. Le gestionnaire d'ordres "APDU" 201a selectionne 
Tapplication "CGA'M/ (par exemple I'application IL) et lui transmet les ordres 
"APDU", ordres traduits et done conventionnels, qu'elle est en mesure de 
comprendre. Cette application est done correctement activee. 

La reponse de I'application IL (Aj) est transmise en sens inverse au 
20 gestionnaire d'ordres "APDU" 201a, a I'agent "APDU" 2010a, puis de 
nouveau a I'agent ATS/ (et de fagon plus generate a I'agent traducteur de 
script). 

La reponse, constitute par un formulaire en langage "HTLM" 
reprend le chemin inverse, par la mise en oeuvre de sessions entre agents 
25 intelligents apparies, pour etre re-transmise au terminal 1 et, eventuellement 
a un serveur eloigne 4 (figure 4), via le reseau Internet f?/, pour atteindre 
finalement I'application OL. 

La figure 6 illustre schematiquement ('architecture logique 
permettant le chargement d'une "applet" selon le procede de I'invention. On 
30 retrouve sur ce schema les blocs materiels constitues par le terminal 1 , le 
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lecteur de carte a puce 3 et la carte a puce 2a, communiquant par mise en 
oeuvre du protocole normalise ISO 7816 precite et Pechange d'ordres 
"APDU", de manure classique en soi. La partie OL est mise en relation avec 
la partie IL (sous forme d'un script reference ILs), par des echanges selon le 
5 protocole Internet "TCP/IP", de la maniere decrite precedemment, par mise 
en oeuvre des fonctions serveur "HTTP" (reference SC) et "CGI" de la carte a 
puce 2a. 

On doit bien comprendre que, bien que represents & I'exterieur de 
la carte a puce 2a pour des raisons de commodite, les blocs SC et ILs sont 
w constitues par differents modules internes de celle-ci, qui ont ete d6crits par 
reference a la figure 5. 

Par contre, le programme OL n'est pas obligatoirement stocks dans 
le terminal 1 . 

On va maintenant detainer un premier exemple de chargement 
15 d'une "applet" dans une carte a puce 2a, par mise en oeuvre de la methode 
dite "GET". 

On suppose que le fichier de chargement de P "applet", r6ferenc§ 7, 
presente la structure illustree par la figure 7 : une entete 70, un corps 
principal 71 constitue par du "Byte Code" en langage "JAVA" et une 
20 signature electronique 72. L'entete represente un identifiant d'une application 
particuliere, gen6ralement appele "Application Identifier" ou simplement 
"AID". La signature electronique 72 est un mot chiffre avec une cle publique 
ou privee, obtenu a partir du code 71. Uensemble du fichier 7 peut 
Sgalement etre chiffre, pour des raisons de confidentiality, lorsqu'il s f agit 
25 duplications dites sensibles. Optionnellement, on peut pr6voir une ou 
plusieurs signature(s) electronique(s) supplementaire(s) non representee(s). 

Les principales etapes du processus sont illustrees 
schematiquement par la figure 8. 

Pendant une premiere §tape, la partie de programme de 
30 chargement OL recupere, par une commande de type "GET", un formulaire 
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de chargement a partir de la carte & puce 2a, formulaire en langage "HTML" 
que Ton appellera arbitrairement "download. html". 

Cette recuperation est effectuee en consultant une page 
correspondante dont I'URL est typiquement de la forme suivante : 
5 http://1 27.0.0.1 :8080/download.html (3), 

dans laquelle http://1 27.0.0. 1:8080 est I'adresse URL de rebouclage 
proprement dite, telle qu'elle a ete definie par la relation (1), et 
"download.html" la page "HTML" a obtenir. Cette requete met en oeuvre une 
session entre agents intelligents comme il a ete decrit en regard des figures 

10 2 a 4, selon un premier aspect de I'invention. La carte a puce 2a joue alors le 
role d'un serveur "WEB". 

La carte a puce 2a envoie le formulaire "download.html" lors d'une 
deuxieme etape, toujours par ouvertures de sessions entre agents 
intelligents apparies, selon le procede de I'invention. Le formulaire obtenu 

15 peut etre affiche sur un ecran 5 par Tintermediaire du navigateur 1 0. 

Pour fixer les id6es, un exemple d'un tel formulaire 8 est illustre par 
la figure 9. Outre diverses zones graphiques et de textes 80 (titre, etc.), le 
formulaire comprend des zones d'affichage pour I'entete 70 du fichier de 
chargement 7, le "Byte Code" 71 et la signature 72. La zone d'affichage 71 

20 est du type dit "TEXTAREA" en langage "HTML" et presente une facilite dite 
d' "ascenseur" pour I'affichage deroulant de textes longs. Les informations 
correspondantes, telles qu'elles apparaissent sur la figure 9, sont purement 
arbitraires. Enfin, on prevoit, de fagon classique en soi, un bouton d'envoi 
"send", reference 81 , et un bouton de remise a zero "reset", reference 82. 

25 Ces boutons sont a la disposition d'un utilisateur du terminal (non 
represente). Le bouton d'envoi 81 permet de valider le formulaire et le 
retransmet & la carte a puce 2a ("soumettre le fichier de chargement" sur la 
figure 8) et le bouton de remise a zero 82 permet d'effacer les informations 
affichees et de re-initialiser le formulaire. 

30 Le code "HTML" necessaire pour programmer un tel formulaire est 

bien connu en soi et est a la portee de I'homme de m6tier. II n'est pas 
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necessaire de le detaillor de nouveau. On peut cependant indiquer qu'il 
contient notamment une ligne de code en langage "HTML" qui se presente 
typiquement sous la forme : 

<form action= M http://1 27.0.01 :8080/cgi-smart/loader"> (4), 
5 dans laquelle http://1 27.0.01:8080 est I'URL de rebouclage de la relation (1), 
cgi-smart le repertoire "CGI" precite contenant le script de chargement 
"loader" que Ton a appele T f script associe a la partie IL du programme de 
chargement. 

Si Taffichage visuel du formulaire 8 sur I'ecran 5 n'est pas souhait§ 
10 (par exemple s'il n'y a pas d'operateur humain, les informations peuvent etre 
cachees incorporant le parametre "HTML" suivant : "TYPE=hidden" dans la 
ligne de code (4) precitee. 

Lors d'une troisieme etape, la partie OL envoie une requete "HTTP" 
de type "GET" a la carte a puce 2a, toujours par ouverture de sessions entre 
15 des agents intelligents apparies. En faisant appel a la fonction "CGI" offerte 
par la carte a puce 2a, telle qu'elle a ete decrite en regard de la figure 5, 
Tapplication IL s'execute, le serveur "WEB" forme par la carte a puce 2a 
passant les parametres de la requete "HTTP" a cette. derniere application. 

La requete precitee contient une ligne de code typiquement de la 
20 forme suivante : 

Smart/loader?AID=xxx&ByteCode=yyy&Signature=zzz (5), 
Dans laquelle "xxx" est I'entete 70 ("2001" dans rexemple de la 
figure 9), "yyy" est le "Byte Code" 71 ("01 23456789 ABCDEF" dans rexemple 
de la figure 9) et "zzz" la signature 6lectronique 71 ("0123456789ABCDEF" 
25 dans Texemple de la figure 9). Les trois parties du fichier de chargement sont 
done bien inserees dans trois champs du formulaire "HTML" 8, sous forme 
concatenee. 

Le chargement d'une "applet" particuliere identifiee par I'entete 70 a 
lieu & ce moment. 

30 Enfin, lors d'une quatrieme 6tape un code de retour est transmis de 

la partie IL a la partie OL, toujours par mise en oeuvre de sessions entre 
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agents appariSs. II s'agit en g6n6ral d'un simple acquittement ou, si 
Poperation ne s'est pas realisee correctement d'un code d'erreur. Dans ce 
dernier cas, il est necessaire de renouveler les etapes 1 & 4. 

Comme solution alternative, il est possible d'utiliser la methode 
5 "POST" precitee. Pour fixer les idees, la figure 10 illustre un exemple d'un tel 
formulaire reference 8'. On retrouve diverses zones de texte et de graphique 
80, une zone d'affichage de Pentete 70 et une zone d'affichage de la 
signature electronique 72, ainsi que des boutons d'envoi "send" 81 et de 
remise a zero "Reset" 82. Ces elements jouent un role tout a fait similaire 

w aux elements de memes reference de la figure 9 et il est inutile de les re- 
decrire. Par contre, la zone d'affichage 71' ne visualise plus explicitement le 
"Byte Code", mais un repertoire ou un sous-repertoire ou le code de P 
"applet" a charger est enregistre. En ('occurrence, cette zone pointe sur un 
fichier, appele arbitrairement "APPLET.BIN", enregistre sur une unite de 

15 stockage appelee "C", qui peut etre un disque dur present dans le terminal 1 . 
Un bouton supplemental de navigation "browse" 83 permet de balayer les 
divers (sous-)repertoires de ce disque et de selectionner un fichier particulier 
("APPLET.BIN"). 

La methode "POST" comme la methode "GET" est bien connue en 
20 soi, et il est inutile de la re-decrire en detail. Dans le cadre precis de 
Tinvention, P "applet" correspondant au fichier "APPLET.BIN" est chargee, a 
partir de Punite "C", de maniere similaire a ce qui a et6 decrit pour la 
methode "GET". 

On va maintenant decrire un deuxieme exemple de chargement 
25 d' "applet" dans la carte a puce 2a. 

II est egalement possible d'enchainer plusieurs formulaires lors du 
chargement. A la place d'un simple statut (acquittement ou code d'erreur 
dans le premier exemple decrite en regard de la figure 8), le retour de la 
partie IL contient alors un nouveau formulaire. Ainsi, des sequences 
30 dynamiques d'echanges entre les parties OL et IL peuvent etre realises. 
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Par exemple, apres analyse du fichier de chargement, la partie IL 
peut demander une autorisation (c'est-a-dire une signature electronique) 
supplemental, par exemple celle d'une instance gouvernementale. Elle 
renvoie alors a la OL un formulaire qui peut avoir typiquement la structure 
5 "HTML" suivante (6) : 


10 


<TITLE>Authorisation form </TITLE> 

<FORM ACTION="http://@carte:8080/cgi-smart/loader ,, > 

<INPUT TYPE="text" NAME="GouvSignature M MAXLENGTH="8">Signature 

</FORM> 


dans laquelle "Authorisation form", entre les balises "HTLM" denommees 
"<TITLE>" et </TITLE>, repr6sente le titre (arbitraire) du formulaire, "(3>carte M 
la traduction litterale de I'adresse URL de rebouclage de la relation (1) et 
15 8080 le numero de port, la ligne de code : 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature 
(7) 

requiert Tentree d'une variable appelee arbitrairement "Signature", en mode 

texte, de longueur maximale 8 octets, et </FORM> est la balise "HTML" 
20 indiquant la fin du code de formulaire. 

Le processus complet comprend alors deux etapes supplementaires 

avant I'etape finale d'acquittement ou de code d'erreur, soit six etapes, 

comme illustre par la figure 1 1 . 

De fagon plus generate, le nombre d f allers et retours peut d6pendre 
25 de parametres figurant dans Tun ou I'autre des formulaires echanges entre la 

carte a puce et la partie OL des programmes de chargement. 

Jusqu'a ce point, la localisation de la partie OL n'a pas ete precisee 

expressement. Outre le fait que le procede rend, a priori, compatible OL et 

IL, il permet aussi une tres grande souplesse pr§cisement quant a cette 
30 localisation, 6tant entendu que la partie IL est stockee dans la carte a puce 

2a comme formant Tune des applications pr§sente dans cette carte a puce. 

Le procede selon I'invention presente notamment Tavantage suppldmentaire 
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de ne plus exiger une proximit6 physique entre les deux parties OL et IL, 
puisqu'elles ne sont plus tributaires du protocole de communication ISO 
7816, les echanges entre ces deux portions de logiciel mettant en oeuvre le 
protocole de communication Internet TCP/IP. 
5 Aussi, la partie OL, ainsi que les donnees proprement dites de 

r "applet" a charger sur la carte a puce 2a peuvent etre stockees soit en 
local, soit dans un site 6loigne. Dans tous les cas cependant, les echanges 
entre ces deux parties mettent en oeuvre, comme il vient d'etre rappele, un 
protocole de communication "TCP/IP" et le chargement d'une "applet" se 
10 deroule comme il a 6te rappele precedemment grace aux fonctions de 
serveur/client "WEB" et "CGI" offertes par la carte a puce 2a. 

On va decrire maintenant, par reference aux figures 12A a 12G, les 
principales architectures pouvant etre mises en oeuvre dans le cadre de 
Tinvention. 

15 La figure 1 2 A illustre une architecture de systeme selon laquelle la 

partie OL est stockee en local sur le terminal 1. Celui-ci est connecte a un 
serveur eloigne 4, via le reseau Internet Rl. Les donnees de I' "applet" a 
charger dans la carte a puce 2a, referencees Da, sont stockees sur ce 
serveur 4. Une requete "HTTP" permet de les transferer vers la carte a puce 
20 2a, via le terminal 1 (et un lecteur de carte & puce non represented par mise 
en oeuvre du protocole de communication Internet "TCP/IP". 

Dans Parchitecture de systeme representee sur la figure 12B, la 
partie de programme de chargement OL et les donnees Da sont stockees 
localement dans le terminal 1. La connexion du terminal 1 au reseau Internet 
Rl est optionnelle. Pour le moins, elle n'est pas requise pour le chargement 
d'une "applet" selon les etapes du procede de Tinvention. Cette connexion a 
ete representee en traits pointings. Le terminal peut done etre autonome. 

Dans ('architecture de systeme representee sur la figure 12C, la 
partie de programme de chargement OL et les donnees Da sont stockees 
dans un serveur distant 4. Les communications entre le serveur 4 et la carte 
a puce 2a, via le reseau Internet Rl, le terminal 1 et le lecteur de carte a 
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puce (non represents) 3'effectue par des requetes "HTTP", et mise en oeuvre 
du protocole "TCP/IP". 

L'architecture de systeme representee sur la figure 12D est similaire 
a celle de la figure 12C. La seule difference est que la partie de programme 
5 de chargement OL est stockee dans un premier serveur distant, reference 
4a, et que les donn6es Da, sont stockees dans un second serveur distant, 
reference 4b. 

Dans l'architecture de la figure 12E, la partie du programme de 
chargement, referencee ici OL', est constitute par un composant du 
w navigateur 10 lui-meme. II s'agit avantageusement d'une "applet" integree 
dans ce navigateur. Le type d'entree a utiliser dans ce cas est "file" (fichier). 

De fagon avantageuse egalement, les donnees Da, de r "applet" a 
charger sur la carte a puce 2a, peuvent etre stockees sur un support 
d'enregistrement de donnees externe 9, par exemple une disquette comme 
15 illustre par la figure 12E. Naturellement d'autres supports sont utilisables : 
CedeROM, bande magnetique, etc. 

Si on utilise la methode "POST" precitee, il suffit de specifier la lettre 
de I'unite de stockage, par exemple "A" pour la disquette 9, un eventuel 
chemin (repertoire, sous-repertoires) et le nom du fichier a charger. Pour 
20 fixer les idees, le chemin complet pourrait etre typiquement : 

A:\APPLET.BIN (8) 
Du fait de la fonction serveur/client "WEB" offerte par la carte a 
puce 2a, selon une des caracteristiques du procede de Tinvention, le 
navigateur 10 est a meme, contrairement a Tart connu, de communiquer 
25 directement avec cette derniere, comme il Ta 6t6 montre en regard des 
figures 2 a 4. Les communications s'effectuent par I'ouverture de sessions 
entre agents apparies. 

Uarchitecture de systeme illustree par la figure 12F est une variante 
de l'architecture de la figure 12E. Selon cette variante, la partie de 
30 programme de chargement OL est stockee dans la carte & puce 2a elle- 
meme, sous forme d'une "applet" en langage "JAVA". Par une requete 
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"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1 , 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Une fois la partie OL chargee, les 
etapes ult6rieures sont communes au cas precedent. Les donnees Da 
5 peuvent egalement etre stockees sur un support externe, par exemple une 
disquette 8. 

^architecture de systeme de la figure 12G est une variante de celle 
de la figure 12F. La seule difference est que la partie de programme de 
chargement OL est stockee sur un serveur eloigne 4, sous forme d'une 
w "applet" en langage "JAVA". Comme precedemment, par une requete 
"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1, 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Les autres etapes sont communes 
au cas precedent. 

15 II est clair que d'autres variantes d'architecture peuvent etre mises 

en oeuvre sans sortir du cadre de I'invention. II est notamment possible de 
charger les donnees Da dans le terminal 1 a partir de diverses sources : par 
exemple a partir d'un autre systeme informatique, connecte au terminal 1 par 
un reseau local ou par tous autres moyens telematiques. 

20 A la lecture de ce qui precede, on constate aisement que I'invention 

atteint bien les buts qu'elle s'est fixes. 

La mise en oeuvre du chargement d'une "applet" dans une carte a 
puce par Interface "CGI" d'un serveur "WEB" loge dans cette carte a puce 
presente notamment les avantages suivants : 

25 L'utilisation de formulaires en langage "HTML" standardise le 

chargement et rend les parties de programmes de chargement OL et IL a 
priori compatibles. En effet, comme il a ete montre, c'est la partie IL situee 
dans la carte a puce qui decrit, dans les champs du ou des formulaire(s) 
renvoye(s), le parametrage de chargement auquel il s'attend. 
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Par ailleurs, ce m6canisme de communication entre les parties de 
programme de chargement OL et IL permet de gerer simplement des 
sequences d'6changes dynamiques lors du chargement. 

^utilisation des protocoles Internet "HTTP" et "TCP/IP" pour les 
5 echanges entre les parties de programme de chargement OL et IL permet de 
les separer physiquement. Seul un routage de paquets "IP" est necessaire 
sur le terminal. Le chargement peut alors se faire dans un lecteur carte a 
puce banalise, puisque Ton conserve le protocole de communication ISO 
7816. Le terminal peut etre un simple micro-ordinateur standard connects a 
w Internet. 

Selon un aspect avantageux egalement du procede de Invention, 
les applications stockees dans la carte a puce restent standards, et done 
n'ont pas a etre re-ecrites. La carte a puce et le terminal eux-memes ne 
necessitent que peu de modifications pour pouvoir accommoder le proc6d§ 
15 de Invention : ces dernieres se resument & I'implantation, dans ces deux 
unites, d'une couche logicielle de protocole de communication qui a ete 
appelee specifique, couche logicielle incluant des agents intelligents. 

Alternativement, la partie de programme de chargement OL peut 
etre chargee dynamiquement sur le terminal, au travers la carte, a partir de 
20 celle-ci ou d f un serveur "HTTP" 6loigne. 

Un simple navigateur Internet peut etre utilise comme programme 
de chargement OL. 

II doit etre clair cependant que I'invention n'est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec 
25 les figures 2 a 12G. 

D'autre part, en lieu et place du langage "HTML", d'autres langages 
similaires, adaptes aux protocoles de communication de type "Internet" 
peuvent etre utilises, notamment le langage "XML". 

L'invention concerne aussi un procede de chargement d'une pi6ce 
30 de logiciel dans une carte a puce a partir d f un terminal connecte k ladite 
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carte a puce par Pintermediaire d'un lecteur de carte & puce permettant des 
communications selon un premier protocole d§termin6, le terminal et la carte 
a puce comprenant des moyens de traitement d'information et des moyens 
de stockage d'information, ledit chargement s'effectuant par la mise en 
5 oeuvre et la cooperation de premier et second programmes de chargement, 
ledit second programme de chargement etant stocke dans les moyens de 
stockage d'information de ladite carte & puce, caracterise en ce qu'il 
comprend au moins les phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans les 
w moyens de stockage d'information de ladite carte a puce (2a), une 

premiere piece de logiciel (23a), formant une couche protocolaire de 
communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans les 
moyens de stockage d'information dudit terminal (1), une seconde 
15 piece de logiciel (13), formant une couche protocolaire de 

communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant I'une 

20 avec i'autre, grace auxdits moyens de traitement d'information du terminal et 
de la carte a puce, de maniere a permettre I'etablissement d'une session 
d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) offre la 
fonctionnalit§ d'un client/serveur "WEB" ; 

25 en ce qu'il comprend une troisieme phase preliminaire consistant & 

implanter dans les moyens de stockage d'information de ladite carte a puce 
(2a) au moins une deuxieme entite logicielle (ATS^ - 47S n ), apte a interpreter 
une suite destructions et a la traduire en une suite d'ordres, de maniere a 
cooperer avec ladite seconde piece de logiciel specifique (23a) pour que 

30 ladite carte a puce offre une fonctionnalite d'interface passerelle dite "CGI", 
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la elite carte k puce conprenant au moins une desdites suites destructions 
associee au dit second orogramme de chargement (IL) ; 
et en ce qu'il comprend au moins les Stapes suivantes : 

1/ ouverture d'une premiere session d'echanges de donn§es 
5 entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 

auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la transmission d'une requete pour que ledit premier 
programme de chargement (OL) recupere des donnees de 
parametrage de chargement fournies par ledit second programme de 
10 chargement (IL) ; 

21 ouverture d'une deuxieme session d'echanges de donnees 
entre ladite carte k puce (2a) et au moins ledit terminal (1) grace 
auxdits moyens de traitement d'information du terminal et de la carte k 
puce, pour transmettre lesdites donndes de parametrage de 
15 chargement au dit premier programme de chargement (OL), lesdites 

donnees de parametrage comportant une reference aux dites 
instructions associees au dit second programme de chargement (IL) ; 
et 

3/ ouverture d'une troisieme session d'echanges de donnees 
20 entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 

auxdits moyens de traitement d'information du terminal et de la carte k 
puce, pour la soumission d'un fichier de chargement (7) prenant en 
compte lesdites donnees de parametrage de chargement, ledit fichier 
comprenant des donnees (70, 71, 72) associees a ladite piece de 
25 logiciel a charger (Da) ; interpretation de ladite suite d'instructions 

associee au dit second programme de chargement (IL), par mise en 
oeuvre de ladite fonctionnalite "CGI", de maniere a generer une suite 
d'ordres transmise au dit second programme de chargement (IL), a 
executer ce programme (IL) et a obtenir ledit dechargement de ladite 
30 piece de logiciel (Da). 
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REVINDICATIONS 

1. Proced§ de chargement d'une piece de logiciel dans une carte a puce & 
partir d'un terminal connecte a ladite carte a puce par I'interm6diaire d'un 
5 lecteur de carte a puce permettant des communications selon un premier 
protocole determine, ledit chargement s'eftectuant par la mise en ceuvre 
et la cooperation de premier et second programmes de chargement, ledit 
second programme de chargement etant stocke dans ladite carte a puce, 
caracterise en ce qu'il comprend au moins les phases suivantes : 

io a/ une premiere phase preliminaire consistant a implanter, dans 

ladite carte a puce (2a), une premiere piece de logiciel (23a), formant 
une couche protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal (1), une seconde piece de logiciel (13), formant une 
15 couche protocolaire de communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant Tune 
avec I'autre de maniere a permettre I'etablissement d'une session 
20 d^changes de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) off re la 
fonctionnalite d'un client/serveur "WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce (2a) au moins une deuxieme entite 
25 logicielle (ATS, - ATS n ), apte a interpreter une suite destructions et a la 
traduire en une suite d'ordres, de maniere a cooperer avec ladite seconde 
piece de logiciel specifique (23a) pour que ladite carte k puce offre une 
fonctionnalite d'interface passerelle dite "CGI", la dite carte a puce 
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comprenant aii moins une desdites suites destructions associ§e au dit 
second programme de chargement (IL) ; 

et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d'une premiere session d'echanges de donnees 
5 entre au moins ledit terminal (1) et ladite carte £ puce (2a), pour la 

transmission d'une requete pour que ledit premier programme de 
chargement (OL) recupere des donnees de parametrage de 
chargement fournies par ledit second programme de chargement (IL) ; 
21 ouverture d'une deuxieme session d'echanges de donnees 

10 entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

transmettre lesdites donnees de parametrage de chargement au dit 
premier programme de chargement (OL), lesdites donnees de 
parametrage comportant une reference aux dites instructions associees 
au dit second programme de chargement (IL) ; et 

15 3/ ouverture d'une troisieme session d'echanges de donnees 

entre au moins ledit terminal (1) et ladite carte a puce (2a), pour la 
soumission d'un fichier de chargement (7) prenant en compte lesdites 
donnees de parametrage de chargement, tedit fichier comprenant des 
donnees (70, 71, 72) associees a ladite piece de logiciel a charger 

20 (Da) ; interpr6tation de ladite suite ^instructions associee au dit second 

programme de chargement (IL), par mise en oeuvre de ladite 
fonctionnalite "CGI", de manure a generer une suite d'ordres transmise 
au dit second programme de chargement (IL), & executer ce 
programme (IL) et a obtenir ledit dechargement de ladite piece de 

25 logiciel (Da). 

2. Procede selon la revendication 1 , caracterise en ce que ledit lecteur de 
carte a puce (3) et ladite carte a puce (2a) comprennent des premiere et 
deuxieme piles protocolaires pour lesdites transmissions de donndes 
selon ledit premier protocole determine, definies par la norme ISO 7816, 
30 chacune comprenant au moins des couches protocolaires de 
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communication logicielles (101, 200a), dites basses, de maniere & 
permettre lesdits tchanges de donnees entre ladite carte a puce (2a) et 
ledit terminal (1), ces couches formant interface avec lesdites premiere 
(13) et seconde (23a) pieces de logiciel sptcifique formant lesdites 
couches protocolaires de communication specifiques, respectivement, et 
en ce que ces pieces de logiciel (13, 23a) comprennent chacune deux 
entites supplementaires constitutes d'un module de transfert de donnees 
(130, 230a), formant interface avec lesdites couches basses (101, 200a) 
des premiere et deuxieme piles protocolaires, et d'un module de gestion 
(131 , 231a), et en ce que lesdites premieres entites de chaque paire sont 
constitutes de modules logiciels, dits agents intelligents (132, 232a1) 
etablissant lesdites sessions. 

3. Procede selon la revendication 2, caracterise en ce que ladite suite 
destructions a interpreter associee au dit second programme (IL) de 

15 dechargement est constitute par un script et en ce que ladite deuxieme 
entite logicielle est constitute par un module logiciel dit agent intelligent 
traducteur de script {ATS, - ATS n ) fournissant des ordres comprehensibles 
par ledit second programme de chargement (OL). 

4. Proctdt selon la revendication 3, caracterise en ce que ladite premitre 
20 etape comprend I'tmission d'une requete de type dit "HTTP" selon un 

protocole de type Internet par adressage d'une page determinee en 
langage "HTML" contenant lesdites donntes de paramttrage, ladite 
adresse ttant une adresse de type "URL" de rebouclage sur ladite carte a 
puce (2a). 

25 5. Proctdt selon la revendication 4, caracttrist en ce que ladite deuxieme 
ttape comprend renvoi par ladite carte a puce (2a) d'un formulaire (8, 8') 
en langage "HTML" et en ce que ledit formulaire (8, 8') comprend au 
moins une adresse de type dit "URL" de rebouclage sur ladite carte a 
puce (2a) et un chemin menant a un rtpertoire dttermint contenant ledit 


5 


10 
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script assocte au dit second programme de chargement (IL), de maniere a 
ce que ce dit premier programme de chargement (OL) recupere les dites 
donnees de parametrage. 

6. Procede selon !a revendication 5, caractSrise en ce que ladite troisieme 
5 6tape comprend renvoi d'une requete de type dit "HTTP" a ladite adresse 
"URL", designant ledit repertoire contenant ledit script associe au dit 
second programme de chargement (IL), ladite requete comprenant 
lesdites donnees representant ladite ptece de logiciel a charger (Da), 
('interpretation dudit script et I'execution dudit second programme de 
w chargement (OL), de maniere a obtenir ledit chargement de la dite piece 
de logiciel (Da). 

7- Procede selon la revendication 6, caracterisS en ce que ladite piece de 
logiciel (Da) est une appliquette ecrite en langage "JAVA" (marque 
deposee). 

75 8. Procede selon la revendication 7, caracterise en ce que ledit fichier de 
chargement (7) est incorpore dans ledit formulaire (8, 8') et comprend une 
entete (70) identifiant ladite appliquette, des donnees (71) et au moins 
une signature electronique (72) obtenue a partir du chiffrement desdites 
donnees. 

20 9. Procede selon la revendication 8, caracterise en ce qu'il comprend au 
moins une premiere etape supplemental, realisee apres ladite troisieme 
etape, et en ce que cette premiere etape supptementaire consiste en 
I'ouverture premiere session supplemental d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

25 transmettre un code predetermine regu par ledit premier programme de 
chargement (OL). 
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10.Proc§d6 selon la revendication 9, caracteris6 en ce que ledit code 
predetermine consiste en un acquittement lorsque lesdites trois premieres 
etapes se sont deroulees correctement ou un code d'erreur dans le cas 
contraire. 

5 11.Proced§ selon la revendication 10, caracterise en ce qu'il comprend au 
moins deux etapes supplementaires, realisees apres ladite troisieme 
etape, comprenant I'ouverture de sessions d'echanges de donn6es 
bidirectionnels entre ladite carte a puce (2a) et au moins ledit terminal (1 ) 
pour la transmission d'un formulaire supplemental requerant la 

10 soumission de donnees supplementaires. 

12. Procede selon la revendication 11, caracterise en ce que lesdites 
donnees supplementaires comprennent une signature electronique 
supplemental. 

13. Procede selon la revendication 12, caracterise en ce que ledit terminal 
15 etant connecte a au moins un serveur eloigne (4) via un reseau de type 

Internet (Rl) et par la mise en oeuvre de protocole de communication de 
type Internet, un desdits agents intelligents (132) est associe a un attribut 
dit de "reseau" permettant des communications avec ledit reseau Internet 
{Rl) et en ce que ledit premier programme de chargement (OL) est stocke 
20 sur Tun desdits serveurs eloignes (4, 4a). 

14. Proc§de selon la revendication 13, caracterise en ce que, ledit terminal 
(1) comprenant un navigateur de type "WEB" (10), ledit premier 
programme de chargement (OU) est constitue par un composant logiciel 
dudit navigateur "WEB" (1 0). 

25 15-Procede selon la revendication 14, caracterise en ce que ledit composant 
logiciel (OL") est obtenu par une etape initiale de chargement dynamique 
d'une appliquette (OL) £crite en langage "JAVA" et stoctee dans ladite 
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carte a puce (2a), ledit chargement etant obtenu par remission d'une 
requete de type "HTTP", avec un adressage de type "URL" de ladite carte 
a puce (2a). 

16.Procede selon la revendication 17, caracterise en ce que ledit composant 
5 logiciel (OL") est obtenu par une etape initiale de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans un 
desdits serveurs eloignes (4), ledit chargement etant obtenu par remission 
d'une requete de type "HTTP", avec un adressage de type "URL" dudit 
serveur eloigne (4). 


WO 01/59563 


PCT/FR01/00393 


1/10 


0L . 1 

' — "OFF-LOADER" j 

1 







s TERMINAL 




"IN-LOADER" \ 

LECTEUR CARTE 


APDU 


CARTE A PUCE , 



IL 


FIG.1A 

ART ANTERIEUR 


ECRAN 


i- 


SERVEUR 
WEB 


MAVIGATEUR 
WEB 


l|l 


MO 12 
OL— T 1 


MODEM 


to 


^ ^Off-Loader 
TERMINAL 


^6b 


P 


20 


CARTE 
A PUCE 


LECTEUR 



RESEAU 

INTERNET 


t: 


6a 


Rl 


FIG.1B 

ART ANTERIEUR 


WO 01/59563 


PCTVFR01/00393 


Jeu d'ordres 



2/10 

Application) ( Application) 



Gestic 
"AP 

nnaire 
DU" 



7816-3 " 


201 


FIQ.1C 

ART ANTERIEUR 


2a. 


NAVIGATEUR 
WEB 


-10 


TERMINAL 


100 



Multiplexer 
de paquets 

L 1 _i- U 


TCP/IP 


-J 


11 


Acces reseau 
0SI1-0SI2 


7816-4 
"APDU" 


01 


102 


7816-3 


I 


I 

LECTEURj 


CARTE A PUCE 



Multiplexeur 
de paquets 

L. i 'J 


23a 


1 


Gestionnaire 
"APDU" 


7816-3 


201a 


•200a 


WO 01/59563 


PCT/FR01/00393 



WO 01/59563 PCI7FR01/00393 



CGI 


OL 


SC 


( — 1 Lit- I 

J"0FF-L0ADER" iOl)\< ^ ► 



I — p- ~i | | ILs 


TERMINAL 


SERVEUR 

http 


IL 
script 


I II I 


LECTEUR 


APDU 


CARTE A PUCE 


2a 


FIG.6 


70 


71 


72 


4 


EN TETE 


"BYTE CODE" 


SI6NATURE 


FIG.7 


WO 01/59563 


PCT/FR01/00393 


5/10 




WO 01/59563 


PCTYFR01/00393 


6/10 


^cran| . J ' 


2a 


TERMINAL 
^10 


NAVIGATEUR 


GET(obfenir"download.html") 


FORMULAIRE 


GEKsoumeftre fichier de chargemennf) 


ACQUITTEMENT/ERREUR 


OL 


CARTE 
A PUCE 


r -| 

l"IN-LOADER-| 

IL 7 


l"OFF-LOADER"l 
L J 


FIG.8 


fcCRAN -T 


TERMINAL 
^10 


NAVIGATEUR 


GET(obt-enir"download.html M ) 


2a 


FORMULAIRE 


GETtsoumettre fichier de chargemennt) 


FORMULAIRE 


GETtsouroet. automation gouvernementale) 


ACQUITTEMENT/ERREUR 


CARTE 
A PUCE 


r 1 

TIN-LOADER"! 


IL' 


OL 


I "OFF-LOADER" 
L J 


FIG.11 


WO 01/59563 


7/10 


PCT/FROl/00393 


8 


70 


71 


72 


Get Method 


ALD 


2001 


7^ 


80 


Byte Code 

0123C56789ABCDEF 


Signature _ 

0123I56789ABCDEF I 


Send 


81 


Reset! 
~3T 


T 
82 


FIG.9 


JtL 


70 

71'- 
72 


POST Method 


ALO 


2001 



Byte Code 

_. ^C- \ APPLET.BIN / 


0123<»56789ABCDEF I 

Send | 

Reset 



81 


' 82 


8' 


I JBrowse...7| 


83 


FIG.10 


WO 01/59563 


PCT/FR01/00393 


8/10 



TCP/IP Rl 



RESEAU , 
INTERNET^ TCP/IP 


FIG.12A 


|serveur[ TCP/IP RI J^ 


l I 


I 


/ 

RESEAU ) 
INTERNET-^ TCP/IP 


1} 


(OU 


Oa 


DONNEES 


TERMINAL 


2a 


APDU 
«* > 


h=t 

(ID 


CARTE 
A PUCE 


FIG.12B 


WO 01/59563 


PCT/FR01/00393 


9/10 



INTERNET—/ TCP/IP 



FIG.12C 



4' RESEAU _ 

INTERNET V / 


TCP/IP 



FIG.12D 


WO 01/59563 


PCT/FR01/00393 


j i ^TCP/IP Rl >j 

SERVEUR, / /-^ 


10/10 10 

OU 


4 RESEAU ) * 

INTERNETS TCP/IP 


FIG.12E 


A 

^ ^ TCP/IP 

i i 


Da 



^/^LlIdisquette 

^DONNEES 


JserveurJ 


RESEAU ) 
INTERNETS TCP/IP 


FIG.12F 

,SERVEUR ^ TCP/ IP Rl ^ 

I | 1 H / 

I i(0L)l I j 

7- * — K V* 

ni / _V. t 



TCP/IP 

RESEAU L 
INTERNET^ T 


•-7 

/ 


FIG.12G 


TAPPLET"! 
1 1 

NAVIGATEUR 


TERMINAL 

l 1 


^VtLllDISQUETTE 
i -^DONNEES 


INTERNATIONAL SEARCH REPORT 


Intfc .onal Application No 

PCT/FR 01/00393 


A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 G06F9/445 H04L29/06 


According lo Intfimaltonal Patent Classil teat ion (iPCt or to both national classification and IPC 


B. FIELDS SEARCHED 


Minimum documentation searched (ctassmcation system followed by classification symbols j 

IPC 7 G06F H04L 


Documentation searched other than minimum documentation to the extern that such documents are included In the fields searched 


Electronic data base consulted during the international search (name ot data base and. where practical, search terms used) 

EPO-Internal 


C. DOCUMENTS CONSIDERED TO BE RELEVANT 


Category " Citation ol document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


WO 98 57474 A (GEMPLUS CARD INT ;MARTINEAU 
PHILIPPE (FR); MERRIEN LIONEL (US); SI) 
17 December 1998 (1998-12-17) 
abstract; claims 1,3,5,6; figure 2 

WO 98 17029 A (TELIA AB) 
23 April 1998 (1998-04-23) 
the whole document 


1,2 


1,2 


□ 


Further documents are listed in the continuation of box C. 


[)( [ Patent family members are listed in annex. 


° Special categories of cited documents : 

'A' document defining the general state of the art which is not 
considered to be of particular relevance 

a E* earlier document but published on or after the international 
filing date 

'L' document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

*0" document referring to an oral disclosure, use. exhibition or 
other means 

'P' document published prior to the international filing date but 
later than the priority date claimed 


*T° later document published alter the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

*X* document of particular relevance: the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

*Y* document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the an. 

■&* document member of the same patent family 


Date ot the actual completion ot the international search 


13 June 2001 


Date of mailing of Ihe international search report 


22/06/2001 


Name and mailing address of the ISA 

European Patent Office. P.B. 5818 Patentlaan 2 
NL-2280HVRijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nf. 
Fax (+31-70) 340-3016 


Authorized officer 


Kingma, Y 


Form PCT/ISAtetO (second sheet) (July 1992) 


INTERNATIONAL SEARCH REPORT 

Information on patent family members 


Intei <onal Application No 

PCT/FR 01/00393 


Patent document 

Publication 


Patent family 

Publication 

cited in search report 

date 


member(s) 

date 

WO 9857474 A 

17-12-1998 

AU 

8113798 A 

30-12-1998 



CN 

1284230 T 

14-02-2001 



EP 

1050145 A 

08-11-2000 



TW 

378308 B 

01-01-2000 



ZA 

9805151 A 

13-04-1999 

WO 9817029 A 

23-04-1998 

SE 

506628 C 

19-01-1998 



EP 

0932956 A 

04-08-1999 



NO 

991756 A 

14-06-1999 



SE 

9603825 A 

19-01-1998 


Form PCT/ISA/210 (patent tamlly annex) (July 1998) 


RAPPORT DE RECHERCHE INTERNATIONALE 


Den .e Internationale No 

PCT/FR 01/00393 


A. CLASSEMENT DE L'OBJET DE LA OEMANOE . 

CIB 7 G06F9/445 H04L29/06 


Seton la classilicalion internationale des brevets (CIB) ou a la lots selon la ctassif teal ion nationaie et la CIB 


B. DOMAINES SUR LESQUELS LA RECHERCHE A PORTE 


Documenlalion minimale consuttee isysteme de ctassilication suivi des symbotes de classemenl) 

CIB 7 G06F H04L 


Documentation consuliee autre que la documenlalion mmimale dans la mesure ou ces documents relevenl des domaines sur lesquels a pone la recherche 


Base de donnees electronique consuliee an cours de la recherche Internationale (nom de la base de donnees. et si realisable, termes de recherche utilises) 

EPO-Internal 


C. DOCUMENTS CONSIDERES COMME PERTINENTS 


Caiegorie " Identification des documents dies. avec. le cas echeant. I'indication des passages pertinents 


no. des revendications vtsees 


WO 98 57474 A (GEMPLUS CARD INT ; MARTI NEAU 
PHILIPPE (FR); MERRIEN LIONEL (US); SI) 
17 decembre 1998 (1998-12-17) 
abrege; revendications 1,3,5,6; figure 2 

WO 98 17029 A (TELIA AB) 
23 avril 1998 (1998-04-23) 
le document en entier 


1,2 


1,2 


] 13 SUi,S dU C3dre ^ P ° Ur ^ ^ te b ^ <l6S d0CUmentS 


10 


Les documents de families de brevets son! indiques en annexe 


• Categories speciales de documents cites: 

•A" document definissanl Tela! general de la technique, non 

considere comme parliculieremenl pertinent 
'E' document anierteur. mais publie a la date de depot international 

ou apres cette date 
'L* document pouvant feter un doute sur une revendication de 

pnorite ou cite pour determiner la date de publication d'une 

autre citation ou pour une raison speciale (telle qu'indiquee) 
*0* document se referent a une divulgation oraJe. a un usage, a 

une exposition ou lous aulres moyens 
■P" document publie avant la date de depot international, mais 

posterieurement a la dale de pnorite revendiquee 


document ulterieur publie apres la date de depot iniemalionai ou la 
date de pnorite et n'appartenenant pas a fetal de la 
technique pertinent, mais cite pour comprendre le prirtclpe 
ou la theorie constituent la base de ('invention 

document particulierement pertinent: rinven tlon revendiquee ne peul 
etre consideree comme nouvelie ou comme impliquant une activite 
inventive par rapport au document considere isolement 

document particulierement pertinent: Tinven tlon revendiquee 
ne peut etre consideree comme impliquant une activite inventive 
lorsque le document est assocte a un ou ptusieurs autres 
documents de meme nature, cette combinaison etant evidente 
pour une person ne du metier 

document qui fait partie de la meme famUle de brevets 


Date a laqueite la recherche internationale a ete effectivement achevee 


13 juin 2001 


Oate d'expedition du present rapport de recherche internationale 


22/06/2001 


Nom et adresse postale de radministralion chargee de la recherche internationale 
Office European des Brevets. P.B. 5618 Patentlaan 2 
NL-2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 
Fax (+31-70) 340-3016 


Foncttonnaire autonse 


Klngma, Y 


Foimutairo PCT/1SA/210 (deuxitme leuile) Quitet 1992) 


RAPPORT DE RECHERCHE INTERNATIONALE 

Renselgnements retatifs aux membrwde families de brevets 


Den. .e Internationale No 

PCT/FR 01/00393 


Document brevet cite 
au rapport de recherche 


Oatede 
publication 


Membrefs) de la 
famine de brevet(s) 


Datede 
publication 


WO 9857474 


WO 9817029 


17-12-1998 


23-04-1998 


AU 
CN 
EP 
TW 
ZA 


8113798 A 


T 

A 


1284230 
1050145 
378308 B 
9805151 A 


SE 
EP 
NO 
SE 


506628 C 
0932956 A 

991756 A 
9603825 A 


30-12-1998 
14-02-2001 
08-11-2000 
01-01-2000 
13-04-1999 


19-01-1998 
04-08-1999 
14-06-1999 
19-01-1998 


Foirautaiu PCTASA/210 (amore families da brevets) fjuilet 1992) 


